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REMARKS 

Claims 1, 3-16, 18-40 are pending. In view of the following remarks, 
Applicant respectfully requests the Office reconsider and withdraw its rejections 
and forward the application on to issuance. 

Claim Rejections 

Claims 1, 3-16, 18-40 stand rejected under 35 U.S.C. § 103(a) over a 
pubhcation by Cohn et al. (hereinafter "Cohn") in view of a publication by 
Flanagan (hereinafter "Flanagan") and further in view of a publication by 
Microsoft (hereinafter "Microsoft"). 

The Claims 

Claim I recites a software architecture for a distributed computing system 
comprising: 



• an application configured to handle requests submitted by remote 
devices over a network; and 

• an application program interface to present functions used by the 
application to access network and computing resources of the 
distributed computing system, the application program interface 
comprising various types related to constructing user interfaces, 
wherein the various types comprise: 

o classes which represent managed heap allocated data that has 

reference assignment semantics; 
o interfaces that define a contract that other types can 

implement; 

o delegates that are object oriented function pointers; 

o structures that represent static allocated data that has value 

assignment semantics; and 
o enumerations which are value types that represent named 

constants. 
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In making out the rejection of this claim, the Office first argues that 
Chapter 19 of Cohn teaches an application and Chapter 17 teaches an "application 
interface" (API), as claimed, "comprising various types related to constructing 
user interfaces". However, the Office then argues that Chapters 5 and 6 teach "an 
API comprising multiple types related to construction user interfaces" and 
"classes which represent managed heap allocated data that has reference 
assignment semantics". The Office then relies on Flanagan for disclosing 
"interfaces", "structures" and "enumerations" and on Microsoft for disclosing 
"delegates". The Office states that it would have been obvious to integrate the 
teachings of these references "because Visual J++ is based on Java, and Flanagan 
teaches details of classes and packages offered by Java, and Microsoft teaches 
delegates address many scenarios that are addressed by function pointers. . ." 

Applicant respectfully disagrees and traverses the Office's rejection. First, 
Applicant submits that it remains unclear what teachings of Cohn the Office is 
relying on for disclosing "an application program interface" (API), as claimed. 
Specifically, on page 3 of the Office Action, the Office argues that Chapters 5 and 
6 teaches an API, as claimed. Then, on page 6 of the Office Action, it 
inexplicably argues that Chapter 19 teaches an API, as claimed. 

Nevertheless, Applicant has thoroughly reviewed Chapters 5, 6, and 19 
and is unable to find any discussion of an API, as recited in this claim. 
Unfortunately, the Office offers no explanation other than to state: "[i]n Java, and 
applets.... Scrollbars; chapter 5, page 1 and Container class; chapter 6, page 1 and 
through out chapters 5 and 6". Applicant fails to see how this statement is 
pertinent and submits that these excerpts simply do not teach the API recited in 
this claim. Instead, Chapter 5 describes how to use Java components with respect 
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to creating a user interface and Chapter 6 describes how to combine and position 
these components. Furthermore, Chapter 17 merely discusses the nature of URLs 
and how they can be used. Missing from these excerpts, and from Cohn in 
general, is any discussion of an API "comprising various types related to 
constructing user interfaces", as claimed. This is not surprising because Cohn is 
described as a book that "tells how to use the language to solve problems" and 
states: "[t]his book is not an API reference". (See Introduction, page 12). 

Additionally, Applicant respectfully submits that the Office is interpreting 
the term "application program interface" in a manner that is inconstant with how 
it is understood and used in the subject application. Applicant respectfully 
reminds the Office that claims are not to be considered in a vacuum, but rather in 
the context of the specification and drawings, (see e.g., MPEP 2106(II)(c), 
2111(1)). In this regard. Applicant directs the Office's attention to page 6 (lines 
8-10) of the subject application, which is one example of how this term is 
understood and used in the context of the subject application. Even a cursory 
inspection of page 6 (lines 8-10) is sufficient to distinguish this claim from any 
teachings found in the cited excerpts of Cohn. This excerpt is reproduced below 
for the Office's convenience: 

As used herein, the phrase application program interface or API 
includes traditional interfaces that employ method or function calls, as 
well as remote calls (e.g., a proxy, stub relationship) and SOAP/XML 
invocations. 

Second, Applicant respectfully submits that the cited excerpts of Flanagan 
neither disclose or suggest an API comprising all of the various types, as claimed. 
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For instance, applicant fails to see how Fig. 19-1 and page 238 of Flanagan 
disclose "interfaces, that define a contract that other types can implement", as 
claimed. Instead, this figure and excerpt merely discuss classes of the java.awt 
package. 

Third, and perhaps most importantly, Applicant respectfiilly reminds the 
Office that to support a conclusion that the claimed subject matter is directed to 
obvious subject matter, either the references must expressly or impliedly suggest 
the claimed subject matter or the examiner must present a convincing line of 
reasoning as to why an artisan would have found the claimed subject matter to 
have been obvious in light of the teachings of the references, (see MPEP 2142 
and 2143.01). 

Here, the Office's only attempt at such an explanation is to state that it 
would have been obvious to combine the teachings of these references "because 
Visual J++ is based on Java, and Flanagan teaches details of classes and packages 
offered by Java". However, upon close examination, this statement merely 
describes the references themselves and fails to explain why one would have been 
motivated to combine their teachings. As such, this statement actually fails to 
articulate any motivation at all. Accordingly, as best as Applicant can discern, 
the Office's argument relies solely on the fact that the references can be 
combined. However, whether or not the references can be combined is irrelevant 
because: "the mere fact that references can be combined or modified does not 
render the resultant combination obvious unless the prior art also suggests the 
desirability of the combination." (MPEP 2143.01, citing In re Mills, 916 F.2d 
680, 16 USPQ2d 1430 (Fed Cir. 1990)). 



15 



O619060915 O:\DOCSlMSlV)S66US\A00215.DOC 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



Furthermore, even if the cited references did disclose or suggest all the 
claimed subject matter, which they do not, it remains unclear why one would 
have been motivated to combine them in a manner similar to this claim. As noted 
above, the Office has not provided any explanation, or even a stated motivation, 
in this regard. Accordingly, applicant can only conclude that the Office has 
impermissibly used the claimed invention as an instruction manual or 'template' 
to piece together the teachings of the prior art so that the claimed invention is 
rendered obvious. Applicant respectfully reminds the Office that "[o]ne cannot 
use hindsight reconstruction to pick and choose among isolated disclosures in the 
prior art to deprecate the claimed invention." (quoting In Re Fine, 837 F.2d 1071, 
1075, 5 USPQ2d 1596, 1600 (Fed. Cir. 1988)). 

Accordingly, in view of the above discussion, the Office has not 
established a prima facie case of obviousness. Hence, for at least these reasons, 
this claim is allowable. 

Claims 3-4 depend from claim 1 and are allowable as depending from an 
allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 1, are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. 

Claim 5 recites an application program interface embodied on one or more 
computer readable media, comprising: multiple types related to constructing user 
interfaces, the types comprising classes which represent managed heap allocated 
data that has reference assignment semantics, interfaces that define a contract that 
other types can implement, delegates that are object oriented function pointers, 
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structures that represent static ailocated data that has value assignment semantics 
and enumerations which are value types that represent named constants. 

In making out the rejection of this claim, the Office relies on the same 
argument that it made with respect to claim 1 except that it does not rely on 
Chapter 17 as teaching "an application program interface", as claimed. Therefore, 
for the reasons set forth above, applicant respectfully traverses this rejection. 

Accordingly, in view of the above discussion, the Office has not 
established a prima facie case of obviousness. Hence, for at least these reasons, 
this claim is allowable. 

Claims 6-15 depend from claim 5 and are allowable as depending from an 
allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 5, are neither disclosed 
nor suggested in the references of record, either singly or in combination with one 
another. 

Additionally, regarding claims 8-15, Applicant submits that the excerpts 
from Cohn that are cited by the Office disclose various classes, not interfaces. 
Accordingly, the Office's reliance on these excerpts is misplaced. 

Claim 16 recites a distributed computer software architecture comprising: 

• one or more applications configured to be executed on one or more 
computing devices, the applications handling requests submitted 
from remote computing devices; 

• a networking platform to support the one or more applications; and 

• an application programming interface to interface the one or more 
applications with the networking platform, the application 
programming interface comprising various types related to 
constructing user interfaces, wherein the various types comprise: 

• classes which represent managed heap allocated data that has 
reference assignment semantics; 
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• interfaces that define a contract that other types can implement; 

• delegates that are object oriented fijnction pointers; 

• structures that represent static allocated data that has value 
assignment semantics; and 

• enumerations which are value types that represent named constants. 

In making out the rejection of this claim, the Office relies on the same 
argument that it made with respect to claim 1 . Therefore, for the reasons set forth 
above, applicant respectfully traverses this rejection. 

Accordingly, in view of the above discussion, the Office has not 
established a prima facie case of obviousness. Hence, for at least these reasons, 
this claim is allowable. 

Claims 18-27 depend from claim 16 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 16, are neither 
disclosed nor suggested in the references of record, either singly or in 
combination with one another. 

Additionally, regarding claims 20-27, Applicant submits that the excerpts 
from Cohn that are cited by the Office disclose various classes, not interfaces. 
Accordingly, the Office's reliance on these excerpts is misplaced 

Claim 28 recites a computer system including one or more 
microprocessors and one or more software programs, the one or more software 
programs utilizing an application program interface to request services firom an 
operating system, the application program interface including separate commands 
to request services comprising services related to constructing user interfaces, 
wherein the application program interface groups API functions into multiple 
namespaces that define a collection of classes which represent managed heap 
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allocated data that has reference assignment semantics, interfaces that define a 
contract that other types can implement, delegates that are object oriented 
fimction pointers, enumerations which are value types that represent named 
constants and structures that represent static allocated data that has value 
assignment semantics. 

In making out the rejection of this claim, the Office relies on the same 
argument that it made with respect to claim 1 . Therefore, for the reasons set forth 
above, applicant respectfully traverses this rejection. 

Accordingly, in view of the above discussion, the Office has not 
established a prima facie case of obviousness. Hence, for at least these reasons, 
this claim is allowable. 

Claim 29 recites a method comprising: 

• managing network and computing resources for a distributed 
computing system; and 

• exposing a set of functions that enable developers to access the 
network and computing resources of the distributed computing 
system, the set of functions comprising functions to facilitate 
construction of user interfaces, wherein the functions are grouped 
into multiple namespaces that define a collection of classes which 
represent managed heap allocated data that has reference 
assignment semantics, interfaces that define a contract that other 
types can implement, delegates that are object oriented function 
pointers, enumerations which are value types that represent named 
constants and structures that represent static allocated data that has 
value assignment semantics. 



In making out the rejection of this claim, the Office simply indicates "see 
rejection of claim 1 above." Therefore, for the reasons set forth above, applicant 
respectfully traverses this rejection. In addition, applicant respectfully submits 
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that the cited references do not disclose or suggest "exposing a set of functions", 
as claimed. 

Accordingly, in view of the above discussion, the Office has not 
established a prima facie case of obviousness. Hence, for at least these reasons, 
this claim is allowable. 

Claim 30 depends from claim 29 and is allowable as depending from an 
allowable base claim. This claim is also allowable for its own recited features 
which, in combination with those recited in claim 30, are neither disclosed nor 
suggested in the references of record, either singly or in combination with one 
another. 

Claim 31 recites a method, comprising creating a namespace with 
functions that enable drawing and construction of user interfaces, the name space 
defining classes which represent managed heap allocated data that has reference 
assignment semantics, interfaces that define a contract that other types can 
implement, delegates that are object oriented function pointers, structures that 
represent static allocated data that has value assignment semantics, and 
enumerations which are value types that represent named constants. 

In making out the rejection of this claim, the Office simply indicates "see 
rejection of claim 5 above." Therefore, for the reasons set forth above, appHcant 
respectfully traverses this rejection. In addition, applicant respectfully submits 
that the cited references do not disclose or suggest "creating a namespace", as 
claimed. 

Accordingly, in view of the above discussion, the Office has not 
established a prima facie case of obviousness. Hence, for at least these reasons, 
this claim is allowable. 
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Claims 32-40 depend from claim 3 1 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features which, in combination with those recited in claim 31, are neither 
disclosed nor suggested in the references of record, either singly or in 
combination with one another. 

Additionally, regarding claims 34-40, Applicant submits that the excerpts 
from Cohn that are cited by the Office disclose various classes, not interfaces. 
Accordingly, the Office's reliance on these excerpts is misplaced 

Conclusion 

Applicant respectfully submits that the Office has failed to establish a 
prima facie case of obviousness for the reasons set forth above. Applicant 
respectfully requests a Notice of Allowability be issued forthwith. 



Respectfiilly submitted, 




Rich Bucher 
Reg. No. 57,971 
(509) 324-9256 ext. 216 
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